home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Apr 90 / MacApp.Tech$ 4⁄13⁄90 / 1058-THINK 3.0 suggestion-Apr90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.8 KB  |  100 lines  |  [TEXT/GEOL]

  1. Item    5411218                         9-April-90        08:00PDT
  2.  
  3. From:   D2458                           Tactics Int'l, David Shillito,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    THINK 3.0 suggestions
  8.  
  9. Item    4616205                         8-April-90        16:25PDT
  10.  
  11. From:   D2458                           Tactics Int'l, David Shillito,PRT
  12.  
  13. To:     NEAL                            Symantec, David Neal,PRT
  14.  
  15. cc:     AUST0338                        AUPtnr - Tactics Int'l,Shillito,IDV
  16.  
  17. Sub:    THINK 3.0 suggestions
  18.  
  19. David,
  20.  
  21. Thank you again for your continued help.
  22.  
  23. My link problems with DebugDebugStr and DebugException WERE INDEED related to
  24. beta software:  I still had old versions of the THINK MacApp “Diffs” and
  25. “Templates” folders lying around instead of the final release ones!!!  It
  26. didn't occur to me that those had anything with the MacApp source conversion
  27. process until I reread your MacApp manual appendix.  So Link is well now, and
  28. I'm sorry about that episode.
  29.  
  30. All busy cursor problems have been resolved with the insertion of {$IFC
  31. qBusyCursor} ... {$ENDC} in all our busy cursor unit's procedures.
  32.  
  33. I am now able to run in THINK Pascal's environment.  It seems to execute our
  34. application without any problems, so far, and I CAN now run under MultiFinder.
  35. This last problem may have been memory-related (see the last paragraph below).
  36. Given the size and complexity of our software, this says a lot for THINK's
  37. environment.
  38.  
  39. However, I can't use the built versions yet as they crash in the initialization
  40. stage, where I am still doing some investigating.  I did resolve an earlier
  41. problem which had to do with the SANE library (see item 1 below).
  42.  
  43. Here are a few suggestions from someone who has had to deal a lot with project
  44. file organization during the last several days:
  45.  
  46.     1) Could your documentation mention to pay close attention to modifying the
  47. seed projects to replace SANELib.lib with SANELib881.lib in the case where the
  48. 68881 option is turned on?  This is particularly important since you provide
  49. seed projects which contain SANELib.lib in them.
  50.  
  51.     2) More generally, could we be warned that the seed projects are GENERAL
  52. and that modified “seeds” are required anytime one's compiler options differ
  53. from the default, or release, options?
  54.  
  55.     3) I think it should be mentioned somewhere that anytime a rebuild of a
  56. large (e.g. MacApp) project is pending (for example, after a change in compiler
  57. options), it is much more efficient and just plain faster to first do a Remove
  58. Objects!  Can this tidbit also be included in your documentation?
  59.  
  60.     4) Because of 1-3, I find that it is NOT worth keeping prebuilt seed
  61. projects around:  they take up too much space (for all 4, probably over 2
  62. megabytes) and in many cases the compiler options are going to change and thus
  63. necessitate a rebuild anyway.  After all, on an 8-meg Mac IIx and the objects
  64. removed, recompiling all of MacApp takes me about 7 minutes (this from memory,
  65. not actually measured)!
  66.  
  67.     5) Long project files are excruciatingly slow to scroll when dragging
  68. entries around (especially in the segment view, although they somehow get
  69. faster the closer you get to the main segment, near the top).  I think this
  70. design philosophy served you well until you undertook MacApp.  Applications
  71. with such large numbers of files and segments have exposed the need to
  72. reevaluate this user interface issue.
  73.  
  74.     6) The above is made much worse by the fact that you don't allow multiple
  75. selections on file or segment entries.  I realize that multiple selections
  76. would probably require some tricky user interface stuff, but why shouldn't
  77. someone be allowed to drag or remove multiple files/segments?  Dragging
  78. multiple segment entries from distinct segments could get quite involved, but
  79. it must be doable.
  80.  
  81.     7) With the lack of multiple selections, put in a command key equivalent
  82. for Remove in the Project menu (perhaps Cmd-“minus sign”).
  83.  
  84.     Finally, I can no longer replicate the compiler crasher case.  As you may
  85. recall, our largest source file (UTDoc.p) was over 8,000 lines of code and I
  86. have since broken it up into 2 files (UTDoc1.p and UTDoc2.p) by divying up the
  87. doc's methods between them.  In addition, I have been using a much larger
  88. MultiFinder partition size for THINK Pascal since I have been able to execute
  89. within the THINK environment (our application requests 2500K of heap space).  I
  90. have just retried combining the 2 source files into one large one and resetting
  91. the partition size to your default 2048, but unfortunately (or fortunately,
  92. from your point of view) no crash.  This may point to a low-memory type of
  93. problem in the original crash set-up.  Could it make sense in the case of the
  94. statement with empty sets I sent you then, i.e. could that statement have
  95. caused some sort of compiler memory shortage given that a very large source
  96. file was open?
  97.  
  98. Yvon
  99.  
  100.